1. Field of the Invention
The invention generally relates to distributed computer systems and/or networks of interconnected computer systems, and more particularly to a method and system providing an administrative checking process over browser-sent changes to server-administrated records of such browser or client, as transacted in a stateless protocol over such distributed computer systems and/or networks of interconnected computer systems.
2. Prior Art
Computers communicating over the World Wide Web (“web”) do so by browser technology and in an environment described as a “stateless” or non-persistent protocol. “Intranet” generally refers to private networks that likewise implement browser technology as does the web. At least in the case of the web, the stateless protocol is denominated as Hypertext Transfer Protocol (“HTTP”). One premise of the web is that all material on the web is formatted in standardized formats as, eg., HTML (Hypertext Format Language) or XML and so on. All information requests and responses conform similarly to a standard protocol. Another premise of the web is that communications vis-a-vis requests and responses are non-persistent. A request comprises a discrete communication which when completed over a given channel is broken. The response thereto originates as a wholly separate discrete communication which is likely to find its way to the requestor by a very different channel.
Among the many possible configurations of computers communicating over such stateless network is the case of say, a subscription client and a service bureau. The service bureau is likely to provide a domain of one or more distributed servers featuring specialized application programs (eg., records administration, calendaring, accounting and so on) as well as administration over or access to distributed memory (eg., database storage) for trustworthy storage of the records/data. The service bureau might specialize in a given field, say administration of healthcare records and accounts. A subscription client to such a service bureau is paying or somehow otherwise remunerating the service bureau for multiple services. These services include access to the server-based application programs, the presumably powerful platforms which execute such application programs, as well as the server-administrated storage of the client's (probably) voluminous records and data, and back-up and maintenance and upgrades and so on. Individual users of a given client group may have machines no more powerful than routine personal desktop or laptop computers. By accessing the service bureau, the client group obtains the benefit of computing and data-storage power far in excess of their own machines.
One problem with stateless protocols (eg., non-persistent communicating) involves the amending of a server-administrated record. A way of illustrating the problem in a stateless or non-persistent protocol is by reviewing a persistent protocol paradigm:—eg., a private data network. So for example, consider a bank and the bank account information it administrates for its customers. This bank might provide a market or region with a number of different branches. The branches feature tellers who service the transactions of the customers by interacting with a computer at the given teller station. The teller-computers are linked (most likely) by copper wire to the bank's central server. Assume that a given customer account might have multiple parties or members of the customer group. For example, a customer group might comprise a parent and a child. Such two members are privileged to deposit or withdraw at will and independently.
The following example is characterized as both an example of ● a persistent protocol in which the server-administrated record (eg., bank account) is ●● “locked” during a given node's (eg., teller's) session with it. Therefore, in a teller transaction utilizing a persistent protocol, a teller who is servicing one member of the customer group forms a persistent connection with the server by accessing the customer account through the teller-machine. The teller is “online” continuously with the server. During the session that the teller is accessing the customer account, the teller is online continuously with that customer's account information. That is, the teller never goes away from its connection with the customer's account until the teller signals the completion of the transaction, or otherwise breaks off the session with that customer account.
During the session, the server “locks” the bank account record, thus barring intervention by any other member of the given customer group, as vis-a-vis a teller at another branch. Again, the server-administrated bank account record is said to be “locked.” During the session that the teller for the given member is interacting with the bank account, the teller is not only “online” continuously, but the interaction is also real-time.
At completion of the session, the teller logs off his or her access of the customer bank account or otherwise breaks the session. The server then “unlocks” the account record for a succeeding transaction. Unlocking the account frees it for access again by any of the members of the customer group for any of their succeeding transactions (again, as through tellers).
Let's say both a parent and a child hold privileges for one bank account. Take as an example the situation when each of the parent and child both wish to withdraw from the account at about the same time and from different branches. In a persistent protocol, things might happen in this sequence. The teller for the first of the two who latches onto the account with the server gets to complete his or her transaction first and to the exclusion of the other because the server “locks” out any teller for other for the duration of the session. After the first of the parent or child completes his or her transaction, the server “unlocks” the account. The second-in-time of the parent and child can then get access to the account, but they find the bank account in the state left by the immediately previous transaction.
Allow us to examine what might happen if the server did not lock the bank account during a teller's session with it. Assume all of the following. That is, that a grandparent, parent and child all hold privileges to a given account, which at beginning of our example, has a balance of $1,000. First, the grandparent steps up before a teller and asks the teller to check the account balance. The grandparent's teller does so, and replies “$1,000.” Elsewhere, the parent steps up before another teller and asks that teller to check the account balance. The parent's teller does so, and replies “$1,000.” In still a different place, the child steps up before still a different teller and asks that teller to check the account balance, who does so and replies “$1,000.” Hence, all three teller's have called in a copy of the account to their teller-machine.
Now, in the same sequence, the grandparent withdraws $100. The grandparent's teller changes the account in the teller's local copy and then transmits the changed copy to the server. The parent deposits $500. So the parent's teller changes the account in that teller's local copy and then transmits that teller's changed copy to the server. The child withdraws $300, which has the child's teller changing the account in that teller's local copy and then transmits that teller's changed copy to the server. In actuality, the account balance should be $1,100. But since the server-administrated record was not locked, each successive teller overwrote the changes entered by the previous teller. Hence the withdrawal and deposit of the grandparent and parent were both overwritten. Only the child's transaction is recorded, it being the last in time while the three concurrent transactions were transpiring. Thus, in error, the account balance shows as $700.
The foregoing gives a good reason for locking the records in a persistent protocol. A real world example of a persistent protocol system is given next.
The system of U.S. Pat. No. 5,642,503—Reiter is an example of operating in a persistent protocol and administrating over server-supervised changes to an official record shared by a plurality of users authorized to do so. The Reiter system 100 provides a work-around of sorts from the conventional access-by-one user a time norm of persistent protocols, with a purported “management of database records that are accessible to multiple users.” Col 1, lines 9-10. As briefly examined as follows, the way the Reiter system 100 actually does so merely introduces other shortcomings.
The Reiter system 100 has a database 106 of ‘official’ records (eg., 201 and 601 in FIG. 6 thereof). The Reiter disclosure actually refers to the database 106's records simply as “record” or “correct record” (Col. 6, line 51) and the like, but nowhere actually refers to them as ‘official.’ The database 106 resides in a given memory set-up 103.
The Reiter system 100 also has a version store 105 residing in memory 101 that is apart from the memory 103 for the database 106. The version store 105 stores and keeps track of historical versions (eg., 202-205) of a record (eg., 201) in the database 106 (see FIG. 2 or 6 thereof). Col 3, lines 37-38. “The version store 105 may be considered a stack-like structure in which versions are added to the top of the stack. For example [see FIG. 2 thereof], the [record] 206 [in database 106] has a first version 202, a second version 203, a third version 204, and fourth version 205 stored in the version store 105.” Col. 3, lines 38-43.
The version store 105 and database 106 reside in memory 101 and memory 103 apart from each other (Col. 3, line 8) because, since “ . . . the number of versions a particular record may have is unbounded, the database may become too large and cause performance of the database to suffer.” Col 1, lines 51-54.
The Reiter system 100 further includes a database server 104. “The database server determines in response to an access request for one of the records by one of the plurality of [users] whether the [user] should have access to the record as stored in the [database] or to a version of the record as stored in the [version store].” Col. 2, lines 3-7. Now it is apparent that, the Reiter system 100 permits only one user at a time with access to the correct record:—all others will have to settle for a historical (and incorrect) version.
The Reiter disclosure refers to a record accessed by a requesting-user not in competition with any other users as an “uncommited entry.” The concept ‘uncommitted’ might be read as ‘checked-out from the database but not yet copied or updated back into it.’ Conversely, the converse concept ‘committed’ might be read as ‘copied or updated back into the database.’ More particularly, “[u]ncommitted entries represent data that is in the process of being changed.” Col. 3, lines 55-56.
Given the foregoing as background, the Reiter system 100 can be understood as an embellishment on server-administrated changes in a persistent protocol, but albeit in a persistent protocol to be sure. That is, a user accessing a record (which will always be deemed a modification transaction) does latch onto the record and consequently lock out all others. “If a user aborts a modification transaction, the uncommitted entry may be copied back into the database.” Col 3, lines 57-59. “When an uncommitted entry exists for a particular user, that user sees the data as it exists in the database, but all other users see entries stored in the version store.” Col. 3, lines 59-62. “Data in an entry in the version store may not be modified, only data in a record in the database may be modified.” Col 3, lines 62-64.
The following sums up the Reiter system 100. When a user requests access to a ‘correct’ record (and regardless whether merely to read it or modify it), the Reiter system 100 determines that the user is either:—
denied access to the ‘correct’ record and instead is served some historic ‘incorrect’ version of the record (with read-only privileges to it);
or,
served the ‘correct’ record along with permission to modify it (whether wanted or not), wherein further such user's access to the record is persistent, and for the duration of the persistence of that user's access, that user has ‘locked out’ everybody else (not from read-only access to some historic ‘incorrect’ version of the record, because that is what they are served, but) from reading or modifying the ‘correct’ record.
The foregoing comprises a background in a persistent protocol. To turn to a stateless (non-persistent) protocol, such as the web or an Intranet, it too presents problems with client-requested changes to server-administrated client records. In a stateless protocol, a user is only intermittently in contact or “online” with the server. After a given intermittent “online” contact, the server has no knowledge or assurance that the user will come back anytime soon.
Let's examine this again in the context of a bank's server administrating a bank account for a customer group consisting of a parent and a child. Assume that the parent acts first. That is, the parent acts first to establish a connection via the Internet or web with the server that administrates the bank account. The contact of the parent with the server functions (among other ways) as a request for the server to grant said teller the privileges and rights to deposit to or withdraw from the bank account. Unlike the persistent protocol, where the server may next lock the account, in a stateless (non-persistent) protocol it is generally an unwise policy to lock the account. Arguably, it is generally a wiser policy to leave the account unlocked at all times. Indeed, these policy concerns are worthy of further examination.
Once again, in a stateless protocol, it is generally unwise to lock a server-administrated client record, ever. It does not help even if the user signals its intention to change the account in advance such that the server can anticipate that the very next transmission will comprise the actual request to change. Locking the account is simply risky. The nature of a stateless protocol has the user's connection breaking off after every discrete communication. Whereas the server can anticipate that in the majority of cases the user will return after it signals its intention to change the account, there is no guarantee. The minority of cases, when the user doesn't return after signaling its intention to change the account, causes the problems if the account is locked. If the account was locked, and then left locked, it remains so all day, all week, until the server master or customer service department personally attends to unlocking it. That is, the usual way a “locked” and abandoned record gets unlocked is because of a flag noticed at the end of some period of business which is attended to personally by the server's master, unless a client call is placed to the customer service department.
For sake of illustration, consider the parent and child accessing the same account, this time over a network in a stateless protocol environment. Assume that the parent logs on first to the server. The parent requests to make a withdrawal except including the reservation that parent wants to the server to send the account balance first in order that parent not overdraw the account. The server might reply with sending the account balance and simultaneously locking the account in anticipation of the parent's succeeding transmission, which ought to be the request for withdrawal. However, assume now that the parent simply does not respond again and goes away for an extended period of time. The server is left with a locked account. Now the child is unable to access the account. The account won't be unlocked probably until it is given personal attention by the server's master or the customer service department. In the competitive business of providing user-convenient service, this scenario inconveniences not only the child (or successive other users of the client group) but also the service bureau.
Let's reconsider the foregoing with the following change. Assume that, following when the parent logs on and requests to an account balance, this time the server chooses to leave the account unlocked. At this stage in the process, the account is unlocked and the parent's connection, which is always only intermittent in a non-persistent protocol, is disconnected. Hence the parent is studying the downloaded account balance information in order to decide what amount to withdraw. With the record unlocked, the child is free to log onto the server and withdraw from the account before the parent ever returns. The parent's later-transmitted request for withdrawal may be denied for insufficient funds. The confounded parent might request for an updated account balance, which the server sends. And, before the parent can re-submit a reduced-amount request for withdrawal, a second child might get in and out and further deplete the account. The foregoing scenario is hardly a hypothetical posit. In fact, it is such a problem in the industry that it has been given an informal name. That is, in cases where a junior user intervenes in a conversation between an earlier user and server and changes the server-administrated record on the slower moving earlier user, it is called “walking on somebodies toes.”
Consequently, a sever faces a dilemma in the administration of server-administrated records for a client group over a stateless (non-persistent) protocol network. On one hand, it is an unwise policy to lock a record for the earliest user. There are multiple reasons why this is unwise, but for which only a very simple example is given above. On the other hand, it is no better a policy to leave the record always unlocked because this affords the opportunity for what is informally getting called “walking on somebodies toes.”
What is needed is a solution for server-administrated record administration in a stateless protocol that overcomes the shortcomings of the prior art.